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REMARKS 

INTRODUCTION 

Claims 1-16 were previously pending and under consideration. 
Claims 17-22 are added herein. 

Therefore, claims 1-22 are now pending and under consideration. 

Claims 10, 11 and 16 are allowed. 

Claims 1-9 and 12-15 are rejected. 

Claims 1-3, 9 and 13-15 are amended herein. 

No new matter is being presented, and approval and entry are respectfully requested. 

CONDITIONAL INTERVIEW REQUEST 

Applicant respectfully requests that the Examiner contact the undersigned for a personal 
or telephonic Interview if, after considering the amendments and remarks herein, the Examiner 
intends to further rely on the Herman reference as the primary basis of rejection. It is 
respectfully submitted that, if necessary, an Interview would be beneficial (1 ) to clarify the 
Applicant's understanding of how the Examiner is interpreting the Herman reference and (2) to 
clarify any outstanding issues and how they might be addressed. 

REJECTIONS UNDER 35 USC § 103 

In the Office Action, at pages 1-5, claims 1-9 and 12-15 were rejected under 35 U.S.C. 
§ 103 as being unpatentable over Herman in view of Houvener. This rejection is traversed and 
reconsideration is requested. 

Claim 1 has been amended to clarify the timing of the recited issuance. Claim 1 now 
recites issuing an identification code "when a user starts a transaction". Claim 1 has also been 
amended to clarify the functional role of the recited code during a transaction's progress. Claim 
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1 now recites "the issued identification code is automatically displayed and used to identify and 
manage the transaction when the user interactively adds/removes commodities to/from the 
transaction before its completion". Finally, as discussed later, claim 1 has been broadened 
slightly to recite a "security token" rather than a "password". See also claims 13-15. 

In some situations, it can be beneficial for a user conducting a transaction to be able to 
identify the particular transaction while it is transpiring. For example, the user may wish to obtain 
assistance or ask a question about a transaction and may need to identify the transaction (e.g. 
transaction number). However, when a mere serial transaction number (or serial number plus 
predictable/known information such as a date) is used displayed and used as a transaction 
identifier during a transaction, it becomes possible for a malicious user to guess or predict an 
identifier (transaction number) of another user, thereby comprising the security of that user's 
transaction. 

In general Herman does not appear to be concerned with details of how a transaction is 
conducted, but rather addresses how a dynamic record of a transaction can be generated and 
used after the transaction. In Herman, whether a transaction code is generated during a 
transaction or at the end of a transaction, it is only generated and possibly displayed upon 
completion of the transaction. This is why Herman uses the traditional term of a "receipt", which 
usually means "a writing acknowledging the receiving of goods or money" (Webster's 
Dictionary). Herman mentions that "Smart Receipts maintain a persistent connection between 
two parties following a successful online transaction" (col. 1 , lines 57-59). This connection is not 
used to add or remove commodities or otherwise manage the transaction before its completion. 
Also, a Smart Receipt is "creat[ed] ... on a merchant site upon successful completion of a 
transaction" (claim 1), and " delivered ... upon successful completion of a purchase" (col. 1, lines 
65). After the transaction is complete and the Smart Receipt has been issued, the Smart 
Receipt is not used by the transactor to edit the transaction (e.g. add/remove commodities), but 
rather is used to provide marketing or communication with the transactor. Herman is not 
concerned with details of how a transaction is conducted, but rather concerns how a dynamic 
record of the transaction can be generated and used. Herman does not appear to solve a 
problem of providing a secure displayable transaction code used to identify and manage a 
transaction while the transaction is occurring. 
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The rejection points to Houvener's display of a credit approval code. However, a credit 
approval code reflects approval of a credit request deemed secure as a result of identification of 
the requesting terminal (see col. 6, lines 21-31). There is no discussion or suggestion in 
Houvener to use a transaction order serial number and a security token as a combined 
transaction code or identifier for display and managing an in-progress transaction. Furthermore, 
the credit approval process described in Houvener is the payment tendering process typically 
performed when a transaction is complete ; i.e. payment at the end of a transaction. Therefore, 
any codes used or returned by Houvener are not analogous. 

The term "password" has been changed to "security token". The Webster's Deluxe 
Unabridged Dictionary describes a token as "something serving as a sign of authority, identity, 
genuineness, etc." The Webster's Third International Dictionary describes a token as 
"something given or shown as a symbol of guarantee (as of authority, right, or identify : 
PASSWORD)". In the art, it is understood that a token can be temporary. 

Withdrawal of the rejection is respectfully requested. 

DEPENDENT CLAIMS 

The dependent claims are deemed patentable due at least to their dependence from 
allowable independent claims. These claims are also patentable due to their recitation of 
independently distinguishing features. For example, claim 6 recites "the identification code is 
issued when at least one commodity is selected at the terminal, the identification code being 
utilized until the user decides to purchase the selected commodity". This feature is not taught or 
suggested by the prior art. Withdrawal of the rejection of the dependent claims is respectfully 
requested. 
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